home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group97a.txt / 000044_icon-group-sender _Mon Feb 24 10:19:49 1997.msg < prev    next >
Internet Message Format  |  2000-09-20  |  7KB
  1. Received: by cheltenham.cs.arizona.edu; Mon, 24 Feb 1997 12:23:44 MST
  2. To: icon-group@cs.arizona.edu
  3. Date: Mon, 24 Feb 1997 10:19:49 -0500
  4. From: Jan Galkowski <jan@solstice.digicomp.com>
  5. Message-Id: <3311B195.794BDF32@solstice.digicomp.com>
  6. Organization: Digicomp Research Corporation
  7. Sender: icon-group-request@cs.arizona.edu
  8. References: <330DAC29.41C67EA6@solstice.digicomp.com>, <5ekvhb$7md@nef.ens.fr>
  9. Subject: Re: What's the biggest Icon program you've written?
  10. Errors-To: icon-group-errors@cs.arizona.edu
  11. Status: RO
  12. Content-Length: 6702
  13.  
  14. Marc Espie wrote:
  15. > 
  16. > In article <330DAC29.41C67EA6@solstice.digicomp.com>,
  17. > Jan Galkowski  <jan@solstice.digicomp.com> wrote:
  18.  
  19. [snip]
  20.  
  21. > A set of functions to manipulate some combinatorial graphs, and display
  22. > the result graphically.
  23. > Roughly 4000 lines (wc says 3936  11172 82247) for the total.
  24.  
  25. Marc,
  26.  
  27.     Thanks to you and to the others that have responded, for your replies.
  28. I am responding to yours because of your solicitation, and because I wanted
  29. to ask some questions.  I intended to summarize what I've found after the
  30. question has "been on the books" for a while.  All responses have been
  31. interesting.
  32.  
  33. > 
  34. > I've got into the main pitfall of Icon: forgetting about failure.
  35. > writing stuff such as i <- value & function(i)
  36. > forgetting that function(i) was not returning anything, or using
  37. > suspended generators, and having them resumed and backtracking and... well,
  38. > ending up with the assignment to i being cancelled where it was not
  39. > intended.
  40.  
  41.     This is interesting.  I would have thought notions of success and failure,
  42. a la logic programming, was a big reason for using Icon.  It is bound to have
  43. serious impacts upon one's design and programming styles if one plans to use it.
  44.  
  45. > 
  46. > The biggest problems I've run into are some limitations of Icon.  There are
  47. > no modules, no import/export mechanism for big projects.
  48.  
  49.     IMO, I'm not sure these are as much limitations of Icon as taking where it
  50. hasn't received much use or wasn't intended to be used.  I can't really answer
  51. that, of course.  I feel it is someplace where it would be useful to have some
  52. support.  But I don't know whether Idol-like solutions are right.  In fact, I
  53. tend to doubt they are.  And I feel I don't want to clutter up the presently
  54. pretty language with other than more built-ins.  That is, I wouldn't want to
  55. change the syntax in any way that would require, for instance, some declarative
  56. sugar on every procedure.
  57.  
  58.     And also, it's not clear that ways of controlling and organizing many small
  59. pieces of text, each with a local scope, belong in a programming language.  I
  60. am in favor of something being there which facilitates this, but that is hardly
  61. a universal or a compelling view. 
  62.  
  63. [snip]
  64.  
  65. > I'm also missing features such as manifest constants. The preprocessor is
  66. > not such a great solution when you end up with a trace that mentions `2'
  67. > and you wrote HIGHLIGHT_COLOR in your source.
  68.  
  69.    This is a problem with a preprocessor, I imagine.  One would almost need
  70. to have a backtrace log of substitutions for an error system to be able
  71. to figure out what the original references were.  Is it worth it?
  72.  
  73. [snip]
  74.  
  75. > I very seldom need co-expressions.  Knowing how they are implemented
  76. > makes them somewhat unsafe for `production' code...
  77. [snip]
  78.  
  79.     Can you be more explicit here?  As far as I know, co-expressions and
  80. the whole generator thing is supported for the Unix world, and for the
  81. DOS world, and at the ProIcon level for the Macintosh world.  That's a chunk
  82. of space.  What in particular do you find "unsafe"?
  83.  
  84. > 
  85. > I'm sincerely hoping they will get better one day. I have a feeling that
  86. > Icon could deal with multi-threaded applications very nicely with just
  87. > a tweak of the coexpression mechanism.
  88.  
  89.     I disagree.  IMO, I think these are two similar things with vastly
  90. different reasons for existence and destinies.  The co-expression mechanism
  91. is a highly distilled and easy to control form of search in the manner of
  92. the AI and logic languages, all the way back to PLANNER and unification,
  93. with the programmer calling most of the shots.
  94.  
  95. [snip]
  96.  
  97. > 
  98. > I've somewhat stopped trying to `sell' Icon to anybody... about the time
  99. > I stopped selling the Amiga to anybody, for mostly the same reasons.
  100.  
  101.   I didn't meaning "selling" in the evangelical sense but, rather, in a business
  102. case to immediate management.  And, if I may read into your post, do you 
  103. mean you feel Icon is as dead as the Amiga is?
  104.  
  105. > 
  106. > There are some arresting problems.
  107. > The fact that Icon is supported by a rather small development team (for
  108. > instance, compiler work is stopped) is a problem. 
  109.  
  110.    I respectfully disagree.  If anything characterizes Icon's implementations,
  111. IMO, it is that elusive attribute called "coherence".  Its opposite is the MS
  112. treatment of a software megolith like Visual Basic. 
  113.  
  114. [snip]
  115.  
  116. > Also, the Icon book is rather hard to come by, for instance.
  117. > You won't find it in specialized libraries, and will have to special-order it.
  118. > All this means that Icon has almost a non-image.
  119.  
  120.    IMO, I think publicization is up to us, the users.  I find the Icon Project an
  121. easy and ready source of documentation.  I feel they are like small businesspeople--
  122. they can't expand without justifying their costs on their existing cash flow.
  123. > 
  124.  
  125. [snip]
  126.  
  127. > There is such a wealth of perl programmers/perl development these days that
  128. > is very difficult to match with Icon. For instance, the text editor nvi
  129. > does procure an interface to perl...
  130. > 
  131.     The "effort threshold" to acceptance of Icon is its innovative concepts.
  132. Without these, such as its ideas on elevating success and failure, it would not
  133. be Icon.  But these new ideas are its raison d'etre, not an obstacle.  
  134.  
  135.     No, I think the problem, rather, is in the way programming is done and
  136. promulgated.  People seem to want to get as much as possible for as little
  137. as possible invested.  While that may be a good model for capital accumulation,
  138. it's not how much of the world works.  One isn't going to make major headway
  139. towards solving difficult software issues and problems without a correspondingly
  140. major change in the way programming is practiced.  It is an exaggeration, but
  141. I would argue that other than means of classifying and tagging small pieces of
  142. text, much of programming practice hasn't advanced much beyond FORTRAN, despite
  143. increases in hardware capability of a hundred thousandfold.
  144.  
  145.    I feel the obstacles one sees to Icon are no different than some of those
  146. to APL or to logic programming in, say, Prolog:  It's just too different a 
  147. mindset.  But, also, I think a paraphrase of the biologists' Law of the
  148. Unspecialized applies here: The next major technology does not generally come 
  149. as a refinement of the mainstream of a previous one but, rather, as a 
  150. dramatic development from what appears to be a curious and isolated
  151. backwater which may, to some, even seem a cul de sac.
  152.  
  153. [snip]
  154.  
  155.    I cannot, in any way, speak for the Icon Project, of course, just as a
  156. very interested user of Icon who has knocked around in strange programming
  157. environments for several  years.
  158.  
  159. -- 
  160.  Jan Theodore Galkowski,
  161.     Developer, tool & numerical methods elf
  162.  Digicomp Research Corporation,
  163.  Ithaca, NY 14850-5720
  164.